home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 #1 / Ham Radio 2000.iso / ham2000 / packet / terminal / dp410 / bcast.doc < prev    next >
Encoding:
Text File  |  1994-10-29  |  25.1 KB  |  685 lines
  1.  
  2. Dieses File lege ich zur Information bei, es beschreibt ziemlich
  3. genau die Implementation des Broadcasts auch bei DP, nicht nur bei TNN.
  4. Auf Anfrage gebe ich gerne die Originaldokumentation von NK6K weiter.
  5. 73 DL8HBS
  6.  
  7.  
  8.  
  9. ALLE @DL         de:DB7KG  17.10.94 22:43   1  25504 Bytes
  10. Mail-Broadcast-Dokumentation
  11. *** Bulletin-ID: 17A404DB0HB ***
  12. R:941017/1522Z @:DK0MNL.#NDS.DEU.EU #:1901 [Salzgitter] *DK8AT* FBB5.15c
  13. R:941017/1310Z @:DB0DJ.#HH.DEU.EU [Hamburg JO53AN OP:DG6XI/DL5HBF DP-4.02]
  14. R:941017/1253z @DB0HRO.#MVP.DEU.EU [Rostock, DB 19b, DL9GNA/DL9GMB/DL9GYA]
  15. R:941017/1154z @DB0HB.#HH.DEU.EU [PBBS HAMBURG, JO43XO, Sysop DF4HR]
  16. de DB7KG @ DB0HB.#HH.DEU.EU
  17. to ALLE @ DL
  18.  
  19.  
  20. Moin,
  21.  
  22. Auf der Interradio '94 wurde die neue Version 1.55 der Digipeater-Software
  23. TheNetNode vorgestellt. Diese Version ermöglicht den Betrieb von Nachrichten-
  24. Broadcast Kanälen. Das verwendete Protokoll ist 100% kompatibel zu dem
  25. bei Satellitenverkehr gebräuchlichen "PACSAT", sodaß die selben Dekodier-
  26. programme verwendet werden können.
  27. Einige Hostmode-Programme unterstützen bereits den Empfang von PACSAT,
  28. weitere werden sicherlich folgen. Ich spiele hier eine Dokumentation ein,
  29. die die meisten Fragen beantworten sollte.
  30.  
  31.  
  32. =============<schnipp>====================<schnapp>=========================
  33.  
  34.  
  35.  
  36.  
  37.  
  38.                           NORD><LINK
  39.  
  40.                   terrestrische Anwendung des
  41.                       PACSAT-Protokolles
  42.  
  43.  
  44.            MANUAL für USER, SYSOPs und Programmierer
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60. I.  Übersicht:
  61.  
  62.  
  63. II. Anwender-Teil:
  64.     1.  Allgemeine Überlegungen zum Mail-Broadcasts als Er-
  65.         gänzung zu einem User-Einstieg
  66.     2.  Beschreibung des PACSAT-Protokolls bei terristrischer
  67.         Anwendung
  68.     3.  PACSAT in der Praxis
  69.  
  70.  
  71. III. SYSOP-Teil:
  72.     1.  Nachrüstung von TheNetNode-Digipeatern mit PACSAT
  73.     2.  Betrieb von PACSAT und Einstieg auf der selben QRG
  74.  
  75.  
  76. IV. Programmierer-Teil:
  77.     1.  AX.25 als Trägerprotokoll für PACSAT-Broadcasts
  78.     2.  PACSAT File-IDentifier
  79.     3.  Aufbau eines PACSAT-Datenframes
  80.     4.  Der PACSAT Nachrichten-Header
  81.     5.  PACSAT MANDATORY HEADER
  82.     6.  PACSAT EXTENDED HEADER
  83.     7.  PACSAT OPTIONAL HEADER
  84.  
  85. Anhänge:
  86.     A.  Konstanten (Auszug)
  87.     B.  Packverfahren
  88.     C.  CRC-Routinen
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95. Das hier beschriebene Protokoll entspricht der aktuellen
  96. Version. Änderungen und Irrtum vorbehalten. Eine Auflistung der
  97. vorkommenden Markenzeichen erspare ich mir.
  98.  
  99.  
  100.  
  101. Diese Dokumentation entstand mit der freundlichen Unterstützung
  102. von DL9HCJ/Matthias, DL5HBF/Ulli, DL9GYA/Roland und DL2LAY/
  103. Kurt. Fragen, Korrekturen, Ergänzungsvorschläge bitte an:
  104.  
  105.                     DB7KG @ DB0HRO.#MVP.DEU.EU
  106.                     Andreas Gal
  107.                     Dorfstaße 34b
  108.                     23617 Stockelsdorf
  109.                     von 17-21 Uhr: 0451/491934
  110.  
  111.                     (oder an eine unserer NORD><LINK
  112.                      Dienststellen :-) )
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119. II.1  Allgemeine Überlegungen zum Mail-Broadcasts als Ergänzung
  120.       zu einem User-Einstieg
  121.  
  122. Beobachtet  man  eine  Zeit  lang sorgfältig  einen  beliebigen
  123. Packet-Radio  Netzeinstieg, fällt schnell auf,  das  der  Digi-
  124. peater  auf  seinem  Einstieg mit sehr hoher Redundanz  sendet,
  125. d.h.   die  selben  Daten  (Nachrichten)  werden  von  mehreren
  126. Benutzern  abgerufen  und  dadurch mehrfach  ausgesendet.  Dies
  127. führt  zu  einer  Verschwendung  der  zur  Verfügung  stehenden
  128. Sendekapazität.  Eigentlich  würde  es  ausreichen,  wenn   EIN
  129. Benutzer  eine  Nachricht abruft und alle  anderen,  die  diese
  130. Nachricht   auch   haben   möchten,  diese   Nachricht   passiv
  131. mitschreiben.  Dies ist leider nur mit sehr wenigen  Programmen
  132. möglich  (z.B.  DigiPoint auf dem ATARI), so daß diese  Methode
  133. zumeist  mit  einem  erheblichen  Aufwand  verbunden  ist.  Ein
  134. weiterer  Nachteil  ist die fehlende Fehlersicherheit,  die  zu
  135. Datenverlußten/Verfälschungen führen kann.  Außerdem  ist  nach
  136. dem   Mitschreiben   von  Hand  zumeist  eine   Nachbearbeitung
  137. notwendig.
  138. Auf  Packet-Radio-Einstiegen, wo die Sendezeit besonders  knapp
  139. ist,  z.B. PACket-SATelliten, wurde von Anfang an ein Verfahren
  140. zum   Nachrichtenaustausch  gewählt,  das  ein   100%   fehler-
  141. gesichertes passives Mitschreiben ermöglicht. Alle Nachrichten,
  142. die   der   Satellit  aussendet,  sind  "an  alle"  addressiert
  143. (Broadcast),  werden  also bei jeder Station  aufgenommen.  Man
  144. kann  dann  im  nachhinein entscheiden  ob  man  die  Nachricht
  145. behalten  möchte oder nicht. Dadurch wird vermieden, die  selbe
  146. Nachricht mehrmals auszusenden. Bei den immer weiter steigenden
  147. Datenmengen auf den Einstiegen ist ein Umstieg auf ein  solches
  148. BROADCAST-Protokoll auch bei PR-Einstiegen sinnvoll.
  149.  
  150. II.2  Beschreibung  des  PACSAT-Protokolls  bei  terrestrischer
  151.       Anwendung
  152.  
  153. Um  einerseits  auf die Erfahrung, aber auch  auf  die  bereits
  154. vorhandenen  Programme  zurückgreifen  zu  können,   hat   sich
  155. NORD><LINK  entschieden,  das  bei den  Packet-Radio-Satelliten
  156. übliche   "PACSAT-Protokoll"  auch   für   den   terrestrischen
  157. Broadcast  zu  verwenden,  d.h. man kann  zur  Dekodierung  der
  158. Nachrichtenbroadcasts  eines  TheNetNode-Digipeaters  auf   die
  159. selbe  Software zurückgreifen, wie man sie für den  Satelliten-
  160. betrieb  benutzt. Als Beispiel sei das Programm "WISP" genannt,
  161. das durch die AMSAT Vertrieben wird.
  162. Da   die  TheNetNode-Broadcastsoftware  aber  teilweise  andere
  163. Grundbedingungen hat, mußten einige Modifikationen  am  PACSAT-
  164. Ablauf  vorgenommen  werden. Satelliten  senden  in  der  Regel
  165. vollduplex,  die meisten (alle?) Digipeater aber  simplex  oder
  166. echoduplex. Somit ist es beim Satelliten-Betrieb möglich, Daten
  167. an die Box zu senden. Dies ist bei der terrestrischen Anwendung
  168. nicht  möglich, da der Digipeater dauersendet und  nicht  hören
  169. kann. Auch ein "REJECT", wie beim Satelliten-Betrieb, ist nicht
  170. möglich,  aber auch nicht nötig. Erstens treten kaum  Störungen
  171. auf  und  andererseits kann der Digipeater  durch  seine  nicht
  172. eingeschränkte  Hörbarkeitszeit erheblich  größere  Datenmengen
  173. umsetzen  als ein Satellit und somit die Fehlerkorrektur  durch
  174. Mehrfachaussenden  der  Nachricht erreichen.  Für  den  PACSAT-
  175. Betrieb  wird mindestens 9600 Baud Übertragungsrate  empfohlen.
  176. Daraus  ergibt  sich  etwa  eine effektive  Datenrate  von  800
  177. Bytes/s, somit etwa 2.8MB pro Stunde und 67MB am Tag. Umschalt-
  178. und  Wartezeiten wie bei Einstiegen entfallen und  erhöhen  die
  179. effektive Datenrate um das 10-15fache !
  180. Pro  Tag  fallen in DL etwa 200 neue Info-Mails an. Der  Knoten
  181. benötigt  je nach Mailumfang etwa 10 Minuten um die  200  Mails
  182. auszusenden. Damit man als Benutzer nicht 24 Stunden am Tag auf
  183. der   Digipeater-QRG  lauschen  muß,  werden  die  letzten  200
  184. Nachrichten  ständig wiederholt. Alle 2 Nachrichten  wird  eine
  185. Nachricht aus dem gesammt-Nachrichtenvolumen der letzten  Tage,
  186. Monate,   Jahre   (je   nach  Plattengröße   des   Digipeaters)
  187. ausgesendet. Somit kann ein Benutzer durch kurzzeitiges zuhören
  188. (20-30  Minuten) die neuen Nachrichten mitschreiben oder  durch
  189. längeres   Mitschreiben  noch  mehr  interessante   Nachrichten
  190. bekommen.
  191. Das  Broadcast-Prinzip beseitigt die Benachteiligung  schwacher
  192. Stationen, die von "Großfunkstellen" plattgebügelt werden. Auch
  193. SWLs können problemlos dem Packetgeschehen folgen.
  194.  
  195. II.3 PACSAT in der Praxis
  196.  
  197. Die  meisten  PACSAT-Broadcast-"Ausgänge"  (Einstieg  wäre  das
  198. falsche Wort) werden mit 9600 Baud ihre Daten senden, d.h.  man
  199. benötigt ein 9600 Baud Modem nach G3RUH/DF9IC. Da man nicht  zu
  200. senden braucht, ist nahezu jeder 70cm TRX geeignet, selbst PLL-
  201. Handys,  die  für den regulären 9600 Baud Betrieb  wegen  ihrer
  202. schlechten Sendeeigenschaften unbrauchbar sind.
  203. Die Dekodierung der PACSAT-Aussendung geht vollautomatisch ohne
  204. Zutun  des Benutzers. PC-Anwender können mit dem Programm  WISP
  205. die  Nachrichten unter Windows (auch im Hintergrund) empfangen.
  206. Durch  das  "Last-In-First-Out"  kann  man  durch  kurzzeitiges
  207. Zuhören  bereits die aktuellsten Nachrichten mitschreiben.  Für
  208. den  ATARI  ermöglicht das Programm "DigiPoint" die Dekodierung
  209. der PACSAT-Aussendungen.
  210.  
  211. III.1 Nachrüstung von TheNetNode-Digipeatern mit PACSAT
  212.  
  213. Um  den  Umstieg auf PACSAT zu erleichtern, wurde  der  PACSAT-
  214. Server  in die Digipeater-Software integriert. Dadurch benötigt
  215. man  keine  weitere Rechnerhardware, als eine außreichend  groß
  216. dimensionierte  Festplatte.  Der  PACSAT-Server  ist  Standard-
  217. Bestandteil der TNN-Software ab Version 1.55. Damit der  Server
  218. automatisch alle Nachrichten aus dem Netz erhält,  muß  er  bei
  219. EINER  Box  in  der Nähe an den S&F angebunden werden.  In  der
  220. Regel ist eine Wartung des PACSAT-Servers durch den Sysop nicht
  221. nötig.
  222. 10  neue  QRGs  im 70cm-ISM-Bereich wurden vom BUS-Referat  für
  223. Broadcast-Ausgänge   bereitgestellt.  Sie   können   mit   ent-
  224. sprechendem  Filteraufwand parallel zu einem  vorhandenen  70cm
  225. Einstieg  im  oberen  Bandbereich benutzt  werden.  Der  Server
  226. macht,  sofern  nicht  anders konfiguriert,  auf  der  Ausgabe-
  227. frequenz Dauertastung, d.h. der TRX ist entsprechend zu  kühlen
  228. und  der  Hardware-Watchdog des Modems außer Betrieb zu setzen.
  229. Es  ist  anzumerken, das eine 9600 Baud (synkron)  Dauertastung
  230. einen  Datenfluß  auf der Tokenring-Seite (asynkron)  von  etwa
  231. 14000  Baud  erfordert. Ein 19k2 Tokenring ist dann  mit  einem
  232. weiteren  Einstieg bereits überlastet. Generell ist für  PACSAT
  233. VANESSA unbedingt zu empfehlen.
  234.  
  235. Wird eine eigene Frequenz für den Broadcast verwendet,  auf dem
  236. mit  Dauertastung  gesendet  werden  soll,  dann ist  bei einem
  237. Tokenring  ein  DAMA-Eprom  auf  diesem Port zu  verwendet. Der
  238. PACSAT-Timer (PA 28) ist auf 10s (Wert : 1000) zu stellen.  Bei
  239. 1200  Baud  kann  der  Timer  auch  höher  gesetzt werden.  Der
  240. PACSAT-Timer  bestimmt  die  Zeit,  die  MAXIMAL  zwischen zwei
  241. PACSAT-Broadcasts  vergeht.  Durch  das  DAMA-Eprom  wird   der
  242. Broadcast  schon früher ausgelöst,  wenn der TNC alle Daten ge-
  243. sendet  hat.  Dadurch fällt der Sender niemals ab.  Der PACSAT-
  244. FrameCount (PA 29)  ist  je  nach Tokenring-Geschwindigkeit und
  245. Belastung einzustellen,  15  bei 9600 Baud und 4 bei  1200 Baud
  246. hat sich als ein guter Wert erwiesen.
  247. Es  ist  drauf zu achten,  das der TNC  nicht überläuft. (siehe
  248. Statistik)
  249. Nach  der  Konfiguration  des  Timings  kann der Broadcast  auf
  250. dem  Port  durch "PACSAT + <port> QST-1"  eingeschaltet werden.
  251. Jetzt   fehlen  noch  Nachrichten.  Irgendeine  Nachbarbox  muß
  252. den  Knoten in  den S&F  eintragen. Usermails  und System-Mails
  253. dürfen dabei NICHT von der Box gesendet werden.
  254. Nachdem  die Box den  Knoten connected  hat, muß sie den Befehl
  255. "BOX" eingeben um in den S&F-Modus zu gelangen.
  256. Der  Sysop  gelangt  durch die  Eingabe des Befehls "PACSAT" in
  257. den Server. Dort kann man mit "I" Informationen abrufen.
  258. Mit dem Befehl  "M <rufzeichen>"  kann der Sysop das Rufzeichen
  259. der S&F Box setzen (in der Regel: KNOTENCALL-2).
  260.  
  261. III.2 Betrieb von PACSAT und Einstieg auf der selben QRG
  262.  
  263. Möchte man die Möglichkeiten des Broadcast testen, kann man auf
  264. einem  vorhanden Einstieg PACSAT-Broadcasts hinzuschalten.  Das
  265. Timing ist dabei frei wählbar. Über die zeitgesteuerten Batches
  266. läßt  sich der PACSAT-Broadcast auch zu den Hauptbetriebszeiten
  267. abschalten  usw. Im Interesse der Bandbelegung  im  ISM-Bereich
  268. ist eine eigene Broadcast-Frequenz vorzuziehen.
  269. Bei  Tokenring-Betrieb  darf kein  DAMA-Eprom verwendet werden,
  270. PA 28 und PA 29 konfigurieren den PACSAT-Umsatz.
  271. Bei VANESSA ist z.Z. der parallel-Betrieb nicht möglich.
  272.  
  273. IV.1 AX.25 als Trägerprotokoll für PACSAT-Broadcasts
  274.  
  275. Damit  PACSAT  störungsfrei parallel zu normalen  Packet  Radio
  276. betrieben   werden  kann,  werden  PACSAT   Frames   in   AX.25
  277. Trägerframes  verpackt.  Es  sind UI  (unnumbered  information)
  278. Frames mit der PID (protocoll Identifier) 0xBB gerichtet an das
  279. Zielrufzeichen   QST-1.   Das   Absender-Rufzeichen   ist   das
  280. Rufzeichen des Satelliten/des Digipeaters.
  281.  
  282. fm DB0HRO to QST-1 ctl UI^ pid BB
  283. <PACSAT-Dateninhalt>
  284.  
  285. Bei  der  Erkennung von PACSAT Frames ist also auf die richtige
  286. PID  und auf das Zielrufzeichen QST-1 zu achten. Da die PID von
  287. der  AX.25  PID F0 abweicht, ist das Aussenden von  PACSAT  mit
  288. einem TNC ohne Änderungen im Hostmode NICHT M╓GLICH.
  289.  
  290. IV.2 PACSAT File-IDentifier
  291.  
  292. Da  die  Länge  des Datenfeldes bei den meisten  TNCs  auf  256
  293. begrenzt  ist, müssen fast alle Nachrichten in mehrere  PACSAT-
  294. Datenframes  zerlegt  werden. Damit  ein  Datenframe  eindeutig
  295. einer  Nachricht zugeordnet werden kann, erhält jede  Nachricht
  296. eine  FID  (FileID).  Diese FID ist ein 4-Byte  LONG,  der  der
  297. Nachricht zugeordnet wird. Jeder PACSAT-Server vergibt eine FID
  298. nur ein einziges mal, d.h. es kann nicht zu Kollisionen kommen.
  299. Das  Dekodierprogramm speichert die FIDs alle Nachrichten,  die
  300. schon  dekodiert  worden sind und vermeidet so einen  doppelten
  301. Empfang.  Dabei  ist zu beachten, das die  FID  nur  für  EINEN
  302. PACSAT-Server  eindeutig ist, sendet  z.B.  DB0HRO  und  DB0LUB
  303. beide  PACSAT  aus,  dann  kann  die  FID  1234567  bei  beiden
  304. unterschiedliche  Nachrichten bezeichnen, das  Dekodierprogramm
  305. muß die Aussendungen also nach Absenderrufzeichen trennen.
  306. IV.3 Aufbau eines PACSAT-Datenframes
  307.  
  308. Jedes  Datenframe,  das ausgesendet wird, erhält  einen  Frame-
  309. Header. Die dort enthaltenen Informationen sind variabel.  Hier
  310. wird nur auf die von TNN benutzte Form eingegangen.
  311. Jedes PACSAT-Frame enthält am Anfang einen 9 Bytes Header, dann
  312. eine  variable  Datenmenge und am Ende noch 2 CRC  (Checksumme)
  313. Bytes. Der Header ist folgendermaßen aufgebaut:
  314.  
  315. Name      Länge    Funktion
  316. <FLAGS>   1 Byte   bestimmt den Typ des Headers, bei TNN  steht
  317.                    hier immer ein PF_O, das das Vorhandensein
  318.                    eines OFFSET-Feldes anzeigt
  319. <FID>     4 Bytes  PACSAT-File Identifier (s. IV.2)
  320. <TYPE>    1 Byte   Typ der Nachricht, bei TNN (z.Z.) 0x00 (Text)
  321. <OFFSET>  3 Bytes  Offset,  an der  die  Datenbytes  in  das
  322.                    Empfangsfile zu schreiben sind
  323.  
  324. Durch  den  3-Byte Offset ist die maximale Filegröße 16MB,  was
  325. auch  für  künftige Baudraten ausreichen sollte. Hat  man  alle
  326. Teile einer Nachricht empfangen, dann erhält man ein File,  das
  327. zuerst  einen  binären Nachrichtenheader enthält  und  dann  im
  328. ungepackten ASCII-Format die eigentliche Nachricht. Die  letzen
  329. beiden   Bytes  im  Trägerframe  bilden  eine  CRC   über   den
  330. Frameheader  und die Datenbytes. Sie werden nach dem  Verfahren
  331. im Anhang berechnet.
  332.  
  333. IV.4 Der PACSAT Nachrichtenheader
  334.  
  335. (freie  Übersetzung  der  englischen Originaldokumentation  von
  336. NK6K)
  337.  
  338. Alle  Elemente des Nachrichtenheaders (file header)  haben  das
  339. selbe Format:
  340.  
  341. <ID><Länge>[<Daten> . . . ]
  342.  
  343. IV.4.1 <ID>-Feld
  344.       2-Byte  Integer,  der  das  Element  identifieziert,  ist
  345.       Bit   15   gesetzt,   handelt  es  sich   um   eine   benutzer-
  346.       definiertes Headerfeld
  347.  
  348.      Die <ID> wird wie alle mehrbyte-Integers mit dem LSB (last
  349.      significant byte) zuerst übertragen, also so wieder der    IBM-
  350.      PC   das   standardmäßig  tut.  Alle  Motorolla-CPUs   notieren
  351.      genau umgekehrt.
  352.  
  353. IV.4.2 <Länge>-Feld
  354.  
  355.      Dieses Feld ist ein unsigned char und gibt die Anzahl  der
  356.      Datenbytes  in dem Headerelement an. Unbekannte Header-elemente
  357.      können so übergangen werden. Auch Header-   elemente, die  eine
  358.      feste Länge haben, haben das length-   Feld.
  359.  
  360. IV.4.3 <Daten>-Feld
  361.  
  362.      Hier  sind die Daten des Feldes enthalten, sie  können  je
  363.      nach Art des Headerelementes unterschiedliche Formate haben.
  364.  
  365.      Der   PACSAT   Nachrichtenheader   wird   immer   unkomprimiert
  366.      übertragen,  selbst wenn die Nachricht selber komprimiert  sein
  367.      sollte (bei TheNetNode z.Z. immer unkomprimierter ASCII-Text).
  368.  
  369.      Das Ende des Headers ist durch ein Element mit der ID 0x0000 (2
  370.      Bytes) und der Länge 0 gekennzeichnet, also die Bytefolge  0x00
  371.      0x00 0x00.
  372.  
  373. IV.5 PACSAT MANDATORY HEADER
  374.  
  375. Der  "MANDATORY  HEADER"  muß  bei  allen  PACSAT  Aussendungen
  376. enthalten   sein.  Er  wird  durch  die  Bytefolge  0xaa   0x55
  377. eingeleitet, danach folgen die Header-Elemente in aufsteigender
  378. Reihenfolge ihrer Ids.
  379.  
  380. IV.5.1 file_number
  381.     ID           :   0x01
  382.     Länge        :   4
  383.     Daten        :   unsigned long file_number
  384.  
  385.     Hier wird der File-Identifier übertragen.
  386.  
  387. IV.5.2 file_name
  388.     ID           :   0x02
  389.     Länge        :   8
  390.     Daten        :   char file_name[8];
  391.  
  392.     <file_name>  ist der Filename ohne Extention  nach  rechts
  393.     mit Spaces (0x20) aufgefüllt, wenn unbekannt dann müssen   hier
  394.     8  Spaces stehen, die Empfangsstation wählt dann einen  eigenen
  395.     Namen. [TheNetNode überträgt hier 8 Spaces]
  396.  
  397. IV.5.3 file_ext
  398.     ID           :   0x03
  399.     Länge        :   3
  400.     Daten        :   char file_ext[3];
  401.  
  402.     Hier gilt das selbe wie für file_name.
  403.     [TheNetNode überträgt hier 3 Spaces]
  404.  
  405. IV.5.4 file_size
  406.     ID           :   0x04
  407.     Länge        :   4
  408.     Daten        :   unsigned long file_size;
  409.  
  410.     <file_size>  bezeichnet die  Gesammtlänge  des  Files, inclusiv
  411.     Header,  die  Magic-Bytes  (0xaa   0x55)   und   der Nachricht.
  412.  
  413. IV.5.5 create_time
  414.     ID           :   0x05
  415.     Länge        :   4
  416.     Daten        :   unsigned long create_time;
  417.  
  418.     Datum,  wann die Datei erstellt wurde. Die Angabe  erfolgt
  419.     in  Unix-Time,  also die Sekunden, die seit dem  1.  Jan.  1970
  420.     vergangen sind.
  421.     [TheNetNode überträgt hier die Uhrzeit, wann die Nachricht
  422.     über den Store&Forward empfangen wurde]
  423.  
  424. IV.5.6 last_modified_time
  425.     ID           :   0x06
  426.     Länge        :   4
  427.     Daten        :   unsigned long last_modified_time;
  428.  
  429.     [TheNetNode überträgt hier die Uhrzeit, wann die Nachricht
  430.     über den S&F empfangen wurde.
  431.  
  432. IV.5.7 seu_flag
  433.     ID           :   0x07
  434.     Länge        :   1
  435.     Daten        :   unsingned char seu_flag;
  436.  
  437.     [Bei terristrischer Anwendung ist dieses Flag immer 0]
  438.  
  439. IV.5.8 file_type
  440.     ID           :   0x08
  441.     Länge        :   1
  442.     Daten        :   unsigned char file_type;
  443.  
  444.     [TheNetNode  verwendet  momentan  nur  Typ  0x00,  ASCII-
  445.     Text-File]
  446.  
  447. IV.5.9 body_checksum
  448.     ID           :   0x09
  449.     Länge        :   2
  450.     Daten        :   unsigned int body_checksum;
  451.  
  452.     body_checksum  ist  die  16-Bit  Summe  aller  Bytes  des
  453.     übertragenen Files ohne den Header (also nur die Nachricht).
  454.  
  455. IV.5.10 header_checksum
  456.     ID           :   0x0a
  457.     Länge        :   2
  458.     Daten        :   unsigned int header_checksum;
  459.  
  460.     wie body_checksum, aber über alle Bytes des Headers.
  461.  
  462. IV.5.11 body_offset
  463.     ID           :   0x0b
  464.     Länge        :   2
  465.     Daten        :   unsigned int body_offset
  466.  
  467.     gibt den Offset des 1. Bytes des übertragen Files an, also
  468.     somit die Länge des Headers. Das File wird direkt hinter dem
  469.     Header übertragen.
  470.  
  471. IV.6 PACSAT EXTENDED HEADER
  472.  
  473. Der "EXTENDED HEADER" beinhaltet weitere Informationen über die
  474. ausgesendete  Nachricht. Einige Elemente sind für  den  terris-
  475. trischen Betrieb uninteressant und haben nur Dummy-Funktion.
  476. Sie sind durch ein * gekennzeichnet.
  477.  
  478. IV.6.1 Source
  479.     ID           :   0x10
  480.     Länge        :   verschieden
  481.     Daten        :   char source[];
  482.  
  483. Dieses Feld bezeichnet den Absender im ASCII-Format.
  484.  
  485. IV.6.2 ax25_uploader*
  486.     ID           :   0x11
  487.     Länge        :   6
  488.     Daten        :   char ax25_uploader[6];
  489.  
  490. Dieses  Feld  bestimmt  das Rufzeichen  der  Station,  die  die
  491. Nachricht gespeichert hat. [bei terristrischer Anwendung stehen
  492. hier 6 Leerzeichen]
  493.  
  494. IV.6.3 upload_time*
  495.     ID           :   0x12
  496.     Länge        :   4
  497.     Daten        :   unsigned long upload_time;
  498.  
  499. Dieses Feld gibt die Uhrzeit des Uploads einer Nachricht in den
  500. Satelliten an. [Bei TheNetNode wird wieder die Empfangszeit aus
  501. dem S&F eingetragen]
  502.  
  503. IV.6.4 download_count*
  504.     ID           :   0x13
  505.     Länge        :   1
  506.     Daten        :   unsigned char download_count;
  507.  
  508. Dieses   Feld   enthält  die  Anzahl  der  Aussendungen   einer
  509. Nachricht. [Bei TheNetNode ist dieses Feld immer 0]
  510.  
  511. IV.6.4 destination
  512.     ID           :   0x14
  513.     Länge        :   verschieden
  514.     Daten        :   char destination[];
  515.  
  516. Dieses Feld bestimmt die Zieladresse. [TheNetNode übergibt hier
  517. die  hierarchische Routingadresse, z.B. DB7KG @ DB0HRO oder IBM
  518. @ DL]
  519.  
  520. IV.6.5 ax25_downloader*
  521.     ID           :   0x15
  522.     Länge        :   6
  523.     Daten        :   char ax25_downloader[6];
  524.  
  525. Dieses  Feld  beinhaltet das Rufzeichen der  Station,  die  die
  526. Nachricht  angefordert hat. [Bei TheNetNode werden  Nachrichten
  527. nach  einem festen Zeitplan gesendet, nicht nach Requests, hier
  528. stehen also wieder nut 6 Spaces]
  529.  
  530. IV.6.6 download_time
  531.     ID           :   0x16
  532.     Länge        :   4
  533.     Daten        :   unsigned long download_time
  534.  
  535. Dieses  Feld  bestimmt die Zeit wann die Nachricht  erfolgreich
  536. empfangen.  [TheNetNode setzt hier die  Uhrzeit  an,  wann  die
  537. Aussendung des Files begannt]
  538.  
  539. IV.6.7 expire_time
  540.     ID           :   0x17
  541.     Länge        :   4
  542.     Daten        :   unsigned long expire_time
  543.  
  544. Dieses  Feld  enthält  die  Uhrzeit/das  Datum  wann  das  File
  545. "ausläuft" und gelöscht werden soll. [Aus diesem Feld kann  die
  546. Lifetime   berechnet  werden:  (expire_time  -  jetzt_zeit)   /
  547. sekunden_pro_tag]
  548.  
  549. IV.6.8 priority*
  550.     ID           :   0x18
  551.     Länge        :   1
  552.     Daten        :   unsigned char priority
  553.  
  554. [Dieses Feld beinhaltet bei terristrischer Anwendung immer 0]
  555.  
  556. IV.7 PACSAT OPTIONAL HEADER
  557.  
  558. Diese  Headerelemente sind alle optional, d.h.  sie  können  in
  559. beliebiger   Reihenfolge  auftreten  und  müssen   nicht   alle
  560. vorhanden  sein.  Es  werden  nur die  für  den  terristrischen
  561. Gebrauch sinnvollen Elemente beschrieben.
  562.  
  563.  
  564. IV.7.1 compression_type
  565.     ID           :   0x19
  566.     Länge        :   1
  567.     Daten        :   unsigned char compression_type;
  568.  
  569. Die  übertragene  Nachricht  kann  komprimiert  werden  um  die
  570. Übertragungskapazität  zu  erhöhen.  Siehe   Anhang   für   die
  571. definierten Packverfahren. [Dies wird z.Z. von TheNetNode  noch
  572. nicht unterstützt, das Packverfahren ist immer 0 und somit aus]
  573.  
  574. IV.7.2 bulletin_id_number
  575.     ID           :   0x21
  576.     Länge        :   verschieden
  577.     Daten        :   char bid[];
  578.  
  579. Die  Bulletin-ID der Nachricht. Bei User-Mails  eventuell  auch
  580. nicht angegeben.
  581.  
  582. IV.7.3 title
  583.     ID           :   0x22
  584.     Länge        :   verschieden
  585.     Daten        :   char title[];
  586.  
  587. ASCII-Title der Nachricht.
  588.  
  589. IV.7.4 user_file_name
  590.     ID           :   0x26
  591.     Länge        :   verschieden
  592.     Daten        :   char user_file_name[];
  593.  
  594. Name  des  Files  beim Absender. [wird gesetzt ist  aber  nicht
  595. weiter von Bedeutung]
  596.  
  597. Anhang A. Konstanten (Auszug)
  598.  
  599. /* Frame-Header Flags */
  600. #define    PF_O                            2
  601.  
  602. /* Header ID's of mandatory Headers */
  603. #define    PH_HEADER_END                   0
  604. #define    PH_FILE_NUMBER                  1
  605. #define    PH_FILE_NAME                    2
  606. #define    PH_FILE_EXT                     3
  607. #define    PH_FILE_SIZE                    4
  608. #define    PH_CREATE_TIME                  5
  609. #define    PH_LAST_MODIFIED_TIME           6
  610. #define    PH_SEU_FLAG                     7
  611. #define    PH_FILE_TYPE                    8
  612. #define    PH_BODY_CHECKSUM                9
  613. #define    PH_HEADER_CHECKSUM              10
  614. #define    PH_BODY_OFFSET                  11
  615.  
  616. /* Header ID's of extended Headers */
  617. #define    PH_SOURCE                       16
  618. #define    PH_AX25_UPLOADER                17
  619. #define    PH_UPLOAD_TIME                  18
  620. #define    PH_DOWNLOAD_COUNT               19
  621. #define    PH_DESTINATION                  20
  622. #define    PH_AX25_DOWNLOADER              21
  623. #define    PH_DOWNLOAD_TIME                22
  624. #define    PH_EXPIRE_TIME                  23
  625. #define    PH_PRIORITY                     24
  626.  
  627. /* Header ID's of optional Headers */
  628. #define    PH_COMPRESSION_TYPE             32
  629. #define    PH_BULLETIN_ID_NUMBER           34
  630. #define    PH_TITLE                        35
  631. #define    PH_USER_FILE_NAME               39
  632.  
  633. Anhang B. Packverfahren
  634.  
  635. 0x00    unkomprimiert
  636. 0x01    komprimiert mit PKARC*
  637. 0x02    komprimiert mit PKZIP*
  638.  
  639. [* wird von TNN nicht unterstützt]
  640.  
  641. Anhang C. CRC-Routine
  642.  
  643. /* CRC für ein Byte verrechnen */
  644. unsigned int gen_crc(unsigned int crc, char data) {
  645.  
  646.     unsigned int y;
  647.  
  648.     crc ^= ((unsigned int)data) << 8;
  649.     for(y = 0; y < 8; y++)
  650.          if( crc & 0x8000)
  651.              crc = (crc << 1) ^ 0x1021;
  652.          else
  653.               crc <<= 1;
  654.     return(crc);
  655.  
  656. }
  657.  
  658. /* CRC eines Frames überprüfen */
  659. void ckcrc(char *frame, int len) {
  660.  
  661.     unsigned int crc = 0;
  662.     int x;
  663.  
  664.     for (x = 0; x < len-2; x++)
  665.         crc = gen_crc(crc, frame[x]);
  666.     crc = gen_crc(crc, frame[x+1]); /* 1. CRC Byte */
  667.     if (gen_crc(crc, frame[x+2]))
  668.         printf("CRC Error\n");
  669. }
  670.  
  671.  
  672. Statt dem langsamen Bit-Verfahren kann man auch über Tabellen
  673. arbeiten, sie können dem TheNetNode Source-Code entnommen
  674. werden.
  675.  
  676. ===================================================================
  677. Wer möchte, kann fertige Dekodierroutinen bei mir bekommen. Anfragen
  678. bzgl komerzielle Nutzung sind zwecklos und werden nicht beantwortet,
  679. alle NORD><LINK Sourcen dürfen ausschließlich in NICHT-KOMERZIELLEN
  680. Hamware-Programmen verwendet werden.
  681.  
  682. 73s de Andreas / DB7KG @ DB0HRO, NORD><LINK
  683.  
  684. >
  685.  
  686.